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(54) VPN system in mobile IP network, and method of setting VPN 



(57) Linked with a position registration procedure in 
a mobile IP, the invention provides a VPN setting service 
using an IP Sec. tunnel between optional terminals with- 
out requiring these terminals to have a specific VPN 
function. This service is provided by a mobile terminal, 
authentication servers, a VPN database, and network 
apparatuses. A home authentication server extracts 
from the VPN database the VPN information of a user 
who has requested the authentication at the time of 
making a position registration request from the mobile 



terminal. The home authentication serverthen posts the 
VPN information to each network apparatus using a pre- 
determined position registration message and an au- 
thentication response message. Based on the posted 
VPN information, the network apparatuses set a VPN 
path by the IP Sec. to between a home network appa- 
ratus and an external network apparatus, between the 
home network apparatus and a predetermined network 
apparatus, and/or the external network apparatus and 
the predetermined network apparatus, respectively. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the invention 

[0001] In recent years, along the wide distribution of 
the Internet, there has been an increase trend that en- 
terprises attempt to decrease their communication costs 
by replacing their exclusive communication lines with a 
virtual path (VPN: virtual private network) on the Inter- 
net. Reinforcing the security on the Internet is essential 
in realizing electronic commercial transactions. As a 
method of realizing this requirement, attention has been 
focused on the IP Security Protocol (hereinafter to be 
abbreviated as the IP Sec). 

[0002] In the mean time, with the full-scale introduc- 
tion of IMT-2000 near at hand : the Internet environment 
has already started to shift toward the mobile environ- 
ment. The introduction of the mobile environment into 
the Internet increases the convenience of the users of 
the Internet. However, this also involves an increasing 
risk of weakening the security of the Internet. Therefore, 
there has been a high demand for a provision of a frame- 
work that protects security in the mobile environment. 
[0003] In the IMT-2000, there have also been made 
many proposals on the system that combines the IP 
Sec. with the IP Mobility Support (hereinafter to be re- 
ferred to as the Mobile IP) prescribed in RFC202 that is 
a basis of the core net architecture. The mobile IP (Mo- 
bile Internet Protocol) is a technique for automatically 
carrying out the IP address management and automat- 
ically transferring the communication packet to a move 
destination of a terminal when the terminal has moved 
from one IP network to another IP network. An agent 
function for executing the transfer of an address is pro- 
vided in a router so that the router can manage both the 
home address of a terminal as its "registered original 
address" and a "care-of-address" as a current address 
of the-. terminal. When the terminal has moved from one 
network to another network, the terminal registers a new 
care-of-address in the router of the network in which the 
home, address exists. Based on a tunneling technique 
of this, arrangement, it becomes possible for this termi- 
nal to receive a message sent to the terminal home ad- 
dress from a person who does not know the movements 
of the terminal. 

[0004] However, the above proposals are based on 
the assumption that the end user terminal has the IP 
Sec. function, as these techniques do not guarantee the 
complete security on the communication path, that is, 
between the home agent and the communication termi- 
nal. According to the above proposals, all the terminals 
participating in the communications need to be 
equipped with the IP Sec. This requirement is not suffi- 
cient as a framework to protect the security in the mobile 
environment. Therefore, there is little meaning in linking 
the mobile IP with the IP Sec. 



Description of the Related Art 

[0005] Fig. 1 shows one example of a structure of a 
network to which the linkage of tne mobile IP with the IP 
5 Sec, according to the existing proposals, has been ap- 
plied. 

[0006] This structure employs both the mobile IP that 
has been proposed by RFC2002 as the IP architecture 
for supporting the mobile environment, and the IP Sec. 

10 as the architecture for realizing the security on the In- 
ternet. From the nature of the mobile IP, it has weak se- 
curity as compared with the normal network. Therefore, 
various systems for reinforcing the security are em- 
ployed including the IP Sec. 

15 [0007] In the example shown in Fig. 1 , an IP Sec. tun- 
nel 6 substitutes for an IP-IP tunnel set between a mo- 
bile agent 21 (a foreign agent, FA) in a network 2 to 
which a user 1 (MN: Mobile Node) prescribed by the mo- 
bile IP has accessed and a mobile agent 31 (a home 

20 agent, HA) in a user's home network 3. In this case, it 
is necessary that VPN information to be used in the IP 
Sec. is set in advance to the mobile agents 21 and 31 
respectively. 

[0008] A dynamic provision of an IP Sec. tunnel 7 is 
25 also included in the above proposals. However, this is 
a system that depends on an automatic key exchange 
(IKE) between the mobile terminal 1 and the mobile 
agents 21 and 31 . This system also requires a separate 
provision of the IP Sec. using an automatic key ex- 
30 change (IKE) in a communication destination host 52 
(CN: Correspondent Node). In this case, it is further nec- 
essary to change the mobile IP 

[0009] In general, a VPN refers to a virtual path of a 
user provided in the Internet using the IP Sec. T the 

35 MPLS, or others. A VPN has no linkage with another 
Internet technique, for example, a differentiated service 
by a user unit. As a result, the service quality guarantee 
of the VPN is carried out based on a sufficient allocation 
of network resources and a uniform priority control, such 

40 as, for example, a simple priority control using a protocol 
number of the IP Sec. protocol as a filtering condition. 
[0010] According to the above-describe system, all 
the terminals participating in the communications need 
to be provided with the IP Sec. Therefore, there is littfe 

45 meaning in providing the IP Sec. service as the network. 
Further, there has been a problem that a network service 
with improved user convenience by freely combining the 
security service with the service quality guarantee can- 
not be provided to the terminals including existing ter- 

50 minals not equipped with the IP Sec. 

SUMMARY OF THE INVENTION 

[0011] It is, therefore, an object of the present inven- 
ts tion to provide a VPN setting service that enables the 
communications in the mobile IP to be carried out by 
using a safe communication path . Linked with a position 
registration procedure in the mobile IP, it is another ob- 
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ject of the present invention to provide a VPN setting 
service to the communication between optional termi- 
nals without requiring the mobile terminals and the com- 
munication terminals to have a specific VPN function. 
This is achieved by dynamically setting a VPN of the IP 
Sec. to a security gateway, for the terminals participating 
in communications, connecting to a public IP network. 
With this arrangement, the VPN service with improved 
user convenience is provided. As a result, it becomes 
possible to differentiate service providers that provide 
the VPN service. 

[001 2] More specifically, the present invention has the 
following objects. 

1) To provide the VPN setting service to between 
optional terminals without requiring the MN 1 and 
the CNs 42 and 52 to have a specific VPN function. 
This service is provided by dynamically setting a 
VPN of the IP Sec. to the security gateways 21 and 

- 31 of the terminals participating in communications, 
connecting to the public IP network, linked with a 
position registration procedure in the mobile IP. 

2) To make it possible to set a VPN with the service 
quality, the security level and the route, assigned 
by users based on a free combination. 

3) To make it possible to automatically update' a 
VPN path along with a move of the MN 1 . 

[0013] Fig. 2 shows an example of a structure of a net- 
work based on the present invention in comparison with 
the structure shown in Fig. 1 . Linked with a position reg- 
istration procedure in the mobile IP, this provides a VPN 
setting service to an optional terminal 1 and hosts 32 to 
52 having communications. This is achieved by dynam- 
ically setting a VPN of the IP Sec. to security gateways 
21 to 51 connecting to public IP networks 2 to 5. 
[0014] Fig. 3 shows an example of a functional block 
structure of the present invention. 
[0015] Terms that are used hereinafter will be briefly 
explained below. MIP (Mobile IP) is the mobile IP pro- 
tocol prescribed by the RFC2002 in all the future expan- 
sions. AAA protocol is a protocol used by the AAA sys- 
tem. In an embodiment of the present invention, the use 
of DIAMETER protocol currently under examination by 
the IETF is assumed. The AAA protocol can be imple- 
mented in all the protocols capable of transmitting infor- 
mation on authentication., authorization, accounting, 
and policy. In the transmission of new information that 
is necessary in the present invention, an expandable at- 
tribute parameter called AVP (Attribute Value Pair) de- 
fined by the DIAMETER protocol is used. The expanded 
attribute is the information on the VPN setting. 
[0016] MN (Mobile Node) indicates a mobile terminal 
that has the mobile IP protocol function. AAA is a name 
used by the IETF for servers that carry out the above- 
described authentication, authorization, and account- 
ing. AAAH is the AAA of a network that has subscriber 
data of an authentication-requesting user, and AAAF is 
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the AAA of a network that does not have subscriber data 
of the user. In addition to the above-described functions, 
the AAA of the present invention has the following func- 
tions. The AAA extracts VPN information of an authen- 

5 tication-requesting user from the VPN database. The 
AAA posts the VPN information to the HA by the HA reg- 
istration request message. The AAA posts the VPN in- 
formation to the FA by an authentication response mes- 
sage via the AAAF. The AAA extracts the VPN informa- 

io tion by a user unit. Further, the AAA determines a VPN 
path. 

[0017] FA (Foreign Agent) is a functional entity de- 
fined by the RFC2002, and is an agent not owning a v 
home address allocated to a mobile terminal. The FA 

'5 decapsulates an encapsulated packet transmitted to a 
care-of-address that is an address of the own node, and 
transfers the decapsuJated packet to a link layer address 
corresponding to the home address. A table called a vis- 
itor list manages this address correspondence. The FA 

20 of the present invention has both the security gateway 
function of the IP Sec. and the edge router function of a 
differentiated service. 

[0018] HA (Home Agent) is a functional entity defined 
by the RFC2002, and is an agent owning a home ad- 

25 dress allocated to a mobile terminal. A packet trans- 
ferred to the HA with a home address of a mobile termi- 
nal as a transmission destination is encapsulated and 
transmitted to a care-of-address of the FA correspond 
ing to the home address. A table called a mobility bind- 

30 ing manages this address correspondence. The HA of 
the present invention has both the security gateway 
function of the IP Sec. and the edge router function of a 
differentiated service. 1 
[0019] PCN (Proxy Correspondent Node) is* a func- 

35 tional entity prescribed in Japanese Patent No. 
2000-32372. On behalf of a communication node (CN: 
Correspondent Node) that does not support the mobile 
IP under the management, the PCN receives a Binding 
update message transmitted to this CN from the HA. 

40 The PCN then sets a binding tunnel to a destination 
- posted by the Binding update message. The PCN of the 
present invention has both the security gateway function 
of the IP Sec. and the edge router function of a differen- 
tiated service. The PCN anaiyzes the VPN information 

45 posted by the MIP protocol, and sets a differentiated 
service to the network kernel and sets a tunne! at the 
assigned security level based on the analyzed VPN in- 
formation. 

[0020] According to the present invention, the user 
50 authentication server and network apparatuses consti- 
tute the IP network that supports the mobile environ- 
ment. When there has been an initial position registra- 
tion request (an authentication request) from the termi- 
nal 1, the authentication server (AAAH) extracts the 
55 VPN information of the user who has requested the au- - 
thentication, from the VPN database. The authentica- 
tion server then posts this VPN information to the net- 
work apparatuses (HA, FA) using the position registra- 
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tion message and the authentication response mes- 
sage. The network apparatuses (HA. FA) set a VPN be- 
tween the HA and the FA based on the posted VPN in- 
formation. When the communication destination termi- 
nal CN exists in other network 4, the network apparatus 
(HA) further sets a VPN to the security gateway (PCN) 
accommodating the communication destination termi- 
nal assigned by the VPN information from the HA. 
[0021] Further, the authentication server and the net- 
work apparatuses update the VPN information cached 
to the authentication server and the network apparatus- 
es linked to the position registration request based on 
the move of the mobile terminal 1 , into new path infor- 
mation. The authentication server and the network ap- 
paratuses further rewrite the VPN information based on 
the position information posted by the mobile IP. As a 
result, a new IP Sec. tunnel is set dynamically between 
the new FA and the HA and between the PCN and the 
new FA : and the VPN path is automatically updated. 
Further, in order to make complete the security protec- 
tion in the data packet transfer to the FA, the IP Sec. 
tunnel is also set in the binding tunnel to the FA at the 
time of a smooth-hand-off. 

[0022] The authentication server (AAAH) of the 
present invention has a VPN database for storing the 
service quality desired by the user, the security informa- 
tion between the security gateways, and a correspond- 
ence table between the VPN information by a user unit 
consisting of the IP addresses of the communication 
destination hosts (CN) forsetting a VPN and the security 
gateway (VPNGW) for accommodating the communica- 
tion destination host, an AAAVPN control section for 
specifying a VPN setting path based on a security gate- 
way (FA) address of the access network 2 to which the 
mobile terminal set in the authentication request mes- 
sage has been connected, a security gateway address 
(HA) of the home network 3 of the mobile terminal, and 
a security gateway (PCN: Proxy CN) address for accom- 
modating the communication destination host (CN) set 
in the user correspondence VPN information and the 
communication destination host extracted from the cor- 
respondence table, and an AAA protocol processing 
section for setting the service quality and the security 
information between the security gateways as a service 
profile, to the authentication response message to the 
access network and the positionregistration message to 
the home network. 

[0023] Further, the network apparatuses (HA, FA, 
PCN) consisting of the security gateways of the present 
invention have an MA (Mobility Agent) protocol process- 
ing section for understanding the service profile file set 
with the VPN information, the RFC2002 and other rele- 
vant expansion protocols, and an MAVPN control sec- 
tion for setting the QoS control for guaranteeing the 
service quality according to the posted service profile 
and a tunnel for guaranteeing the security between the 
security gateways. 

[0024] The MA protocol processing section in PCN al- 



so carries out a protocol processing of receiving, on be- 
half of the CN not supporting the mobile IP under the 
management, a Binding update message sent from the 
HA to this CN. and setting, on behalf of the CN, the bind- 

5 ing tunnel to the FA by using the IP Sec. tunnel, based 
on the service profile set with the VPN information post- 
ed by the Binding update message. 
[0025] When the security protection has been re- 
quested by the service profile at the time of setting the 

10 tunnel, the MAVPN control section of the network appa- 
ratus (HA) in the home network 3 of the mobile terminal 
(MN) 1 sets the IP Sec. tunnel in place of the normal 
IP-IP tunnel as the tunnel directed from the HA pre- 
scribed by the RFC2002 to the network apparatus (FA) 

? 5 in the external network 2 that is the current connection 
point of the mobile terminal. In the mean time, when the 
security protection has been requested by the service 
profile, the MAVPN control section at the FA side sets 
the IP Sec tunnel in place of the IP-IP tunnel as the tun- 

20 nel (usually called a reverse tunnel) from the FA to the 
HA. 

[0026] As described above, according to the present 
invention, finked with the position registration procedure 
in the mobile IP, a VPN using the IP Sec. can be set 

25 dynamically to the security gateways of the terminals 
participating in communications, connecting to the pub- 
lic IP network. Therefore, it is possible to provide the 
VPN setting service between optional mobile terminals 
(MN) and communication destination hosts (CN) without 

30 requiring the terminals and the hosts to have a specific 
VPN function. Further, as the VPN setting service can 
be provided at the network side, the users can assign 
service quality, a security level, and a path based on a 
free combination of these items by the users. 

35 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0027] The present invention will be more clearly un- 
derstood from the description as set forth below with ref- 
40 erence to the accompanying drawings. 

[0028] Fig. 1 is a diagram showing an example of an 
application of the mobile IP plus the IP Sec. according 
to existing proposals. 

[0029] Fig. 2 is a diagram showing an example of a 
^5 structure of a network according to the present, inven- 
tion. 

[0030] Fig. 3 is a diagram showing an example of a 
functional block structure relating to the present inven- 
tion. 

50 [0031] Fig. 4 is a diagram showing a first embodiment 
of the present invention. 

[0032] Fig. 5 is a diagram showing an example of a 
structure of a VPN database. 

[0033] Fig. 6 is a diagram showing an example of a 
55 detailed functional block structure of the AAA. 

[0034] Fig. 7 is a diagram showing an example of a 

structure of a VPN information cache. 

[0035] Fig. 8 is a diagram showing a CN-GW address 
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correspondence table. 
[0036] Fig. 9 is a diagram showing an example of a 
total processing flow of the AAA. 

[0037] Fig. 10 is a diagram showing an example of a 
processing flow of an AAA protocol processing section. 5 
[0038] Fig. 11 is a diagram showing a message cor- 
respondence table in Fig. 10. 

[0039] Fig. 12 is a diagram showing an example of a 
processing flow of an AAAVPN control section. 
[0040] Fig. 13 is a diagram showing an example of a 10 
processing flow of a VPN path determination control 
section. 

[0041] Fig. 14 is a diagram showing an example of a 
detailed functional block structure of the MA (FA, HA, 
PCN); 15 
[0042] Fig. 15 is a diagram showing an example of a 
structure of an IP Sec. information table. 
[0043] Fig. 16 is a diagram showing an example of a 
structure of a route table. 

[0044] Fig. 17 is a diagram showing an example of a 20 
total processing flow of the MA. 

[0045] Fig. 18 is a diagram showing an example of a 
processing flow of an MA protocol processing section. 
[0046] Fig. 19 is a diagram showing an example of a 
processing flow of an AAA protocol processing section. 25 
[0047] Fig. 20 is a diagram showing an example of a 
processing flow of a mobile IP protocol processing sec- 
tion. 

[0048] Fig. 21 is a diagram showing a message cor- 
respondence table in Fig: 20. 30 
[0049] Fig. 22 is a diagram showing an example of a 
processing flow of an MAVPN control section. 
[0050] Fig. 23 is a diagram showing an example of a 
processing flow of a QoS control section. 
[0051] Fig. 24 is a diagram showing an example of a 35 
processing flow of a tunnel control section. 
[0052] Fig. 25 is a diagram showing a second embod- 
iment. 

[0053] Fig. 26 is a diagram showing a third embodi- 
ment. • *. 40 
[0054] Fig. 27 is a diagram showing a fourth embod- 
iment. 

[0055] Fig. 28 is a diagram showing a fifth embodi- - 
ment. 

[0056] Fig. 29 is a diagram showing a sixth embodi- 45 
ment. 

[0057] Fig. 30 is a diagram showing a seventh em- 
bodiment. 

DETAILED DESCRIPTION OF THE PREFERRED 50 
EMBODIMENTS 

[0058] Fig. 4 shows a first embodiment of the present 
invention. 

[0059] This shows an example of a setting of a VPN 55 
(when a VPN exists between a stationary HA and a CN) 
at the time of an initial position registration. This as- 
sumes a case where a certain user has made a contract 
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with an ISP (Internet Service Provider) providing a VPN 
service that the user can receive an automatic VPN set- 
ting service when the user makes access to the user's 
company through a public network. To facilitate the un- 
derstanding of the present invention, a further detailed 
structure and operation of each functional block of the 
present invention shown in Fig. 3 will be explained below 
where necessary in the explanation of the present em- 
bodiment. 

[0060] In Fig. 4, a user 1 who wants the above service 
first makes a VPN contract (SLA: Service Level Agree- 
ment) with an enterprise 5 and a home ISP 3 ). The 
contract covers an SPI (Security Parameter Index) and 
keys to be used, the service quality, and a list of users 
that can utilize this VPN. Based on this SLA, the enter- 
prise sets VPN information of a HA 31 of the ISP3 to a 
VPNGW apparatus 51 of the own enterprise. The ISP 
sets a domain address of this enterprise, SPI and the 
keys to a VPN database of the user indicated to the en- 
terprise. Further, the ISP registers the domain address 
of the enterprise and the address of the VPNGW appa- 
ratus 51 in a CN-GW correspondence table as VPN in- 
formation 35, and also sets the inability of dynamic set- 
ting of a VPN to a GW type. 

[0061] Fig. 5 shows an example of a structure of the 
VPN database used in the present invention. ^ 
[0062] A VPN database 34 is a set of VPN^data in- 
stances 1 to n that' have been set by users - Each in- 
stance corresponds to one VPN. Each VPN^ r data in- 
stance consists of a Profile Number that is an identifier 
for uniquely expressing this VPN information, a Network 
Access Identifier of the user (NAI), a VPN share indica- 
tor (vpnshare) that expresses whether a security rela- 
tionship shared between the security gateways is to be 
used or a user own security relationship is to be used, 
an IP address of a communication destinatiomterminal 
(destaddr), a QoS class in an .upward direction (up- 
class), a QoS in a downward direction (downclass), an 
upward SPI to be used by the IP Sec. (upSPI), and a 
downward SPI to be used by the IP Sec. (downSPI). 
[0063] When zero (0) has been set to the VPN share 
indicator, it is possible to omit the upclass, the down- 
class, the upSPI, and the downSPI. This database is 
searched using the user NAI, and all the searched in- 
stances are recorded and added with the address infor- 
mation into a VPN information cache to be described 
later. The database search protocol used for searching 
data depends on the product of the database that pack- 
ages the VPN database. Usually, the LDAP (Light Di- 
rectory Access Protocol) and the SQL are used. Fig. 8 
to be described later shows the CN-GW correspond- 
ence table of the VPN information 35. 
[0064] Next, the user 1 connects to an optional access 
point- of an ISP 2 that has a roaming contract with the 
home ISP 3 with whom the enterprise has contracted, 
and the user 1 transmits a position registration request 
(Reg Req) of the mobile IP (© ). As a result, the user 1 
can utilize the network. FA21 , that becomes a,connec- 



EP 1 176 781 A2 



10 



BNSDOCtD: <EP. 



,117S781A2_.L> 



9 

tion point of the ISP 2 having the roaming contract, in- 
cludes this registration request in an authentication re- 
quest message (AMR) ((3) ). and transmits this authen- 
tication request message to AAA (AAAH) 33 of the home 
ISP 3 of the user via an AAA sever (AAAF) 23 within the 
own ISP. 

[0065] The AAAH searches the VPN database 34 by 
the NAI included in the authentication request message 
(AMR), and extracts the VPN information 35 own to this 
user. From the CN-GW address correspondence table, 
it can be known that it is not possible to dynamically set 
a VPN to the domain address of the enterprise assigned 
as the communication destination in the VPN database. 
Therefore, the AAAH sets two VPNs including a VPN 
between the FA and the HA and a VPN between the HA 
and the enterprise GW to a VPN information cache to 
be described later. Next, the AAAH transmits a position 
registration request message (HAR) added with the pro- 
files of the two VPNs, to the HA (@ ). 
[0066] Fig. 6 shows an example of detailed functional 
blocks of the AAA, and Fig. 7 to Fig. 12 show examples 
of their operation. 

[0067] In Fig. 6, AAA 33 (and AAA 23) consists of an 
application server 305, a network kernel 303, and phys- 
ical network device interface 304, in addition to the AAA 
protocol control section 301 , and the AAAVPN control 
section 302, both shown in Fig. 3. The AAA protocol con- 
trol section 302 consists of an AAA protocol processing 
section 311 for controlling the AAA protocol. 
[0068] The AAAVPN control section 302 consists of a 
VPN information cache 312 for caching the VPN infor- 
mation extracted from the VPN database (shown in Fig. 
5), a VPN path determination control section 313, and 
a key generator 315. Fig. 7 shows an example of the 
VPN information cache 312. The VPN information 
cache 312 is a set of VPN information cache instances 
1 to n. The VPN information cache 312 is searched by 
using a session ID that includes unique user own infor- 
mation in a network effective while a user is making ac- 
cess to the network. Each of the VPN information cache 
instances 1 to n consists of a session ID as a unique 
identifier, a profile number that shows a number of VPNs 
set by the user, and VPN information profiles 1 to n that 
include set information of each VPN. 
[0069] Each of the VPN information profiles 1 to n con- 
sists of a profile number as an identifier for uniquely 
identifying a VPN, an IP address of a transmitter and an 
IP address of a destination for specifying a packet to 
which a VPN is applied, a transmitter net mask and a 
destination net mask, a TOS value to be set to the pack- 
et, a security type for showing whether the IP Sec. is to 
be set by the AH. the ESP or by only encapsulation, a 
transmitter gateway address and a destination gateway 
address that are an entrance and an exist of the IP Sec. 
tunnel referred to by the IP Sec. tunnel mode, a desti- 
nation gateway address type for showing whether a 
VPN can be set dynamically to the destination gateway 
or not, an upward SPI (Security Parameter Index) and 



10 

a downward SPI as identifiers of the security, an upward 
ESP encryption key and a downward ESP encryption 
key. and an upward authentication key and a downward 
authentication key. 
5 [0070] The VPN path determination control section 
313 has a CN-GW address correspondence table 314. 
Fig. 8 shows an example of the CN-GW address corre- 
spondence table. The CN-GW address correspondence 
table consists of address instances 1 to n, each includ- 
io jng a CN address/net mask, a GW address, and a GW 
type. This table is searched using the CN address/net 
mask (an enterprise domain address) as a key. 
[0071] The application server consists of a VPN da- 
tabase 34, and a WEB application 36. The network ker- 
is nel 303 is an operating system for controlling a transfer 
to the IP packet and a physical interface as a connection 
point to the network. The physical network device inter- 
face 304 is an interface (a hardware control driver) to a 
physical network device, and is usually a NIC card of a 
LAN. 

[0072] Fig. 9 to Fig. 13 show examples of a process- 
ing flow of the AAA. 

[0073] Fig. 9 shows an example of a total processing 
of the AAA. When the network kernel 303 has received 
a packet from the physical network interface 304, the 
network kernel 303 selects an AAA signaling packet 
based on a port number, and delivers the information of 
the received packet to the AAA protocol control section 
301 (S100). Fig. 10 shows an example of a processing 
flow of the AAA protocol processing section 311. First, 
the AAA protocol processing section 31 1 makes a deci- 
sion on the received message based on a command 
code AVP (an attribute parameter) of the received AAA 
protocol (S101). When the message is the authentica- 
tion request message (AMR), the process proceeds to 
step S102. When the message is an authentication re- 
sponse message (AMA) to be described later, the proc- 
ess proceeds to step S1 03. When the message is other 
message, the process proceeds to step S104. 
[0074] In the present example, the AAAVPN control 
section 302 is started (S102). Next, the AAA protocol 
processing section 311 sets the VPN information ex- 
tracted from the VPN database 34 to the VPN informa- 
tion cache (S103). Then, the AAA protocol processing 
section 31 1 edits the corresponding message according 
to the CN-GW correspondence table, for example, sets 
a differentiated service, and transmits a result (S104). 
A profile cache AVP to the effect that the VPN informa- 
tion cache has been set is set to the authentication re- 
sponse message (AMA) and the position registration re- 
quest message (HAR) that are transmitted by the AAAH 
33. Fig. 11 shows a message correspondence table (a 
relationship among a transmission message, a recep- 
tion message, and aprocessing unit of these messages) 
at step S104 shown in Fig. 10. 

[0075] Fig. 1 2 shows an example of a processing flow 
of the AAAVPN control section 302. First, the AAAVPN 
control section 302 searches the VPN database 34 by 
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the NAI of the mobile terminal, and reads the corre- 
sponding VPN information (S105). Next, the AAAVPN 
control section 302 starts the VPN path determination 
control section 313 (S106). When the SPI (Security Pa- 
rameter Index) read from the VPN database 34 is a de- 
fault SPI, the AAAVPN control section 302 finishes the 
processing. When the SPI read from the VPN database 
34 is not a default SPI, the AAAVPN control section 302 
generates a separate key with the key generator 315 
(S108). 

[0076] Fig. 13 shows an example of a processing flow 
of the VPN path determination control section 313. The 
VPN path determination control section 31 3 extracts the 
address of the VPNGW (FA) 21 at the MN 1 side from 
the request originating host address of the authentica- 
tion request message (AMR) (SI 09). Further, the VPN 
path determination control section 313 searches the 
CN-GW address correspondence table 314 by the CN 
address read from the VPN database 34, and reads the 
address of the VPNGW 51 at the CN 52 side and the 
VPNGW type (S110). 

[0077] Next, when the VPNGW type is the one to 
which a VPN can be set dynamically, the process pro- 
ceeds to step S112. When the VPNGW type is the one 
to which a VPN cannot be set dynamically, the process 
proceeds to step S113. In the present example, the 
processing at step S113 is carried out. The VPN path 
determination control section 313 sets the address of 
the HA 31 to the transmission originating GW address 
of the VPN information posted to the HA 31 , and sets 
the address of the G W 51 read from the CN-GW address 
correspondence table 314 to the destination GW ad- 
dress. Further, the VPN path determination control sec- 
tion 313 sets the address of the FA 21 to the transmis- 
sion originating GW address of the VPN information to 
be posted to the FA 21 , and sets the address of the HA 
31 to the destination GW address HA 31 . Then, the VPN 
path determination control section 313 finishes the 
processing (sets a path to the FA, the HA and the CN). 
[0078] In the mean time, when the VPNGW type is the 
one to which a VPN can be set dynamically, the VPN 
path determination control section 31 3 sets the address 
of the FA 21 to the destination GW address of the VPN 
information posted to the HA 31, and sets the address 
of the GW 51 read from the CN-GW address corre- 
spondence table 314 to the destination GW address. 
Further, the VPN path determination control section 313 
sets the address of the FA 21 to the transmission origi- 
nating GW address of the VPN information to be posted 
to the FA 21 , and sets the address of the GW 51 read 
from the CN-GW address correspondence table to the 
destination GW address. Then, the VPN path determi- 
nation control section 313 finishes the processing (sets 
a path to between the FA and the CN (or the PCN)). 
[0079] Referring back to Fig. A, the HA 31 caches the 
VPN information added to the position registration re- 
quest message (HAR) that has been received from the 
AAAH 33, and further maps an assigned differentiated 



service. Thereafter, the HA 31 sets an IP Sec. tunnel (2) 
from the HA 31 to the enterprise GW 51 , and sets an IP 
Sec. tunnel (3) from the HA 31 to the FA 21, based on 
the path information received. Further, the HA 31 sets 

5 the information for decoding a packet of an opposite- 
direction tunnel to an IP Sec. information table to be de- 
scribed later. As the IP Sec. tunnel (1 ) from the GW 51 
at the enterprise side to the HA 31 has already been 
fixed based on the initial contract setting (SLA), it is not 

10 necessary to set this IP Sec. tunnel (1) from the HA 31 
to the enterprise GW 51 . The HA 31 transmits the posi- 
tion registration response message (HAA) to the AAAH 
33' after finishing the position registration processing 

(CD). 

is [0080] When the AAAH 33 has received the position 
registration response message (HAA), the AAAH 33 ex- 
tracts a VPN between the FA and the HA from the VPN 
information cache 312 (see S113 in Fig. 13). The AAAH 
33 then transmits to the AAAF 23 an authentication re- 
sponse message (AMA) added with the VPN profile to 
be set to the FA 21 (@ ). The AAAF 23 caches the VPN 
information to within the AAAF 23 to follow the move 
within the local domain of the MN 1 , and transfers this 
VPN information to the FA 21 (reference S101, S103 
25 and S104 in Fig. 10). * 

[0081] The FA 21 caches the VPN information added 
to the authentication response message (AMA)fand fur- 
ther maps an assigned differentiated service. Thereaf- 
ter, the FA 21 sets an IP Sec tunnel (4) from the FA 21 
30 to the HA 31 . Further, the FA 21 sets the information for 
decoding a packet of an opposite-direction tunnel to the 
IP Sec. information table. Last, the FA 21 returns the 
registration response message (Reg Rep) to the MN 1 
((7) ). As a result, the VPNs from the access point of the 
35 MN 1 to the GW 51 of the enterprise have been set. Fur- 
ther, as a packet of a user who has not been assigned 
by the enterprise is not transferred via the IP Sec. tunnel, 
it is possible to prevent an unauthorized user from mak- 
ing an illegal access to the enterprise. It is also possible 
40 to avoid making a troublesome contract with a plurality 
of ISPs and SLAs. 

[0082] Fig. 1 4 shows detailed functional blocks of the 
MA (FA, HA, PCN), and Fig. 15 to Fig. 24 show exam- 
ples of operations. 

45 [0083] In Fig. 14, each network apparatus of the FA, 
the HA and the PCN consists of an MA protocol control 
section 321 , an MAVPN control section 322, a network 
kernel 323, and a physical network device interface 324. 
The MA protocol control section 321 consists of an AAA 

50 protocol processing section 331 for controlling the AAA 
protocol, and a mobile IP protocol processing section 
332 for controlling the mobile IP. The MAVPN control 
section-322 consists of a VPN information cache 333 for 
caching the VPN information posted by the AAA or the 

55 MIP protocol, a QoS control section 334. and a tunnel 
control section 335. 

[0084] The VPN information cache 333 has a similar 
structure to that explained with 'reference to Fig. 7. The 
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OoS control section 334 sets io the network kerne! 323 
filter, information consisting of a TOS value set to the 
VPN information cache 333, a transmission originating 
address and a destination address for identifying a 
packet that marks the TOS value, and their net masks. 
The tunnel control section 335 rewrites an output device 
of a route table 337 to a virtual device in a destination 
IP address that has been set in the VPN information 
cache 333. Further, the tunnel control section 335 sets 
to an IP Sec. information table 336, a transmission orig- 
inating IP address and a destination IP address, their 
net masks, a security type, a transmission originating 
gateway address and a destination gateway address, 
an upward SPI and a downward SPI as identifiers of the 
security, an upward ESP encryption key and a down- 
ward ESP encryption key, and an ESP authentication 
key. The tunnel control section 335 encrypts and encap- 
sulates a packet output from the network kernel 323 to 
the virtual device, by referring to the IP Sec. information 
table 336. 

[0085] Fig. 15 shows an example of the IP Sec. infor- 
mation table 333. The IP Sec. information table consists 
of IP Sec. information, ESP information, and tunnel in- 
formation. The IP Sec. information is a collection of IP 
Sec. information instances, and is specified by a set of 
a transmission originating address and a destination ad- 
dress. Each IP Sec. information instance consists of a 
transmission originating address/net mask, a destina- 
tion address/net mask, an actual destination address as 
an actual transfer destination of a packet, a tunnel infor- 
mation identifier to be applied to this packet, and an ESP 
information identifier to be applied to this packet. The 
ESP information is a collection of ESP information in- 
stances. This ESP information consists of an ESP iden- 
tifierfor uniquely identifying ESP information, an encryp- 
tion method, a direction, an AH authentication key 
length, an ESP authentication key length, an ESP en- 
cryption key length, an AH authentication key, an ESP 
authentication key, and an ESP encryption key. The tun- 
nel information is a collection of tunnel information in- 
stances. The tunnel information consists of a tunnel 
identifier for uniquely identifying tunnel information, an 
encapsulation method, a direction, and a transmission 
originating address and a destination address that be- 
come an entrance and an exit of a tunnel. 
[0086] The network kernel 323 is an operating system 
for controlling a transfer of an IP packet and a physical 
interface as a connection point to the network, and has 
a routing table 337 for determining a transfer route of 
the IP packet. The network kernel 323 carries out the 
encapsulation of the IP packet, the packet editing, and 
the control of packet transmission queue. These func- 
tions depend on the operating system, and therefore, 
they will not be explained in the present invention. 
[0087] Fig. 16 shows an example of the routing table 
337. The general routing table consists of a destination 
address, a gateway address, a net mask, a metric, an 
exit interface, and other control auxiliary information. A 



route is determined based on the destination address 
and the metric. In the present invention, a network ker- 
nel that does not depend on a structure of the route table 
but can set a virtual device to an output destination will 
5 be explained in detail below. The network kernel has a 
function of decapsulating an encapsulated packet upon 
receiving this packet. When a packet after the decapsu- 
lation includes the ESP header, the network kernel has 
a function of decoding the encrypted packet by referring 

10 to the ESP information held in the tunnel control section 
335. The physical network device interface 324 is an in- 
terface (a hard control driver) to a physical network de- 
vice. The physical network device is a package or an 
NIC card of, for example, a LAN : an ISDN, an ATM. etc. 

15 [0088] Fig. 1 7 to Fig. 24 show examples of a process- 
ing flow of the MA. The MA processing according to the 
present invention will be explained below with reference 
to these examples of the processing flow. 
[0089] Fig. 17 shows a total processing flow of the 

20 MA. Upon receiving a packet from the physical network 
interface 324, the network kernel 323 decapsulates and 
decodes the encrypted packet as briefly explained 
above, and then discriminates the received packet be- 
tween a signaling packet and a data packet (S200). The 

25 selection of a signaling packet is determined based on 
whether the packet has been received by a port number 
assigned by the MA protocol control section 321 or not. 
When the received packet is a signaling packet, the 
process proceeds to step S201 , and when the received 

30 packet is not a signaling packet, the process proceeds 
to step S203. 

[0090] When the received packet is a signaling pack- 
et, the network interface 324 delivers the information of 
the received packet to the MA protocol control section 

35 321 , and then the MA protocol control section 321 car- 
ries out the AAA protocol processing 331 and the mobile 
IP protocol processing 332 (S201). Next, the MAVPN 
control section 322 is started to carry out the VPN infor- 
mation (S202). At step S203, the network kernel 323 de- 

40 termines the interface to the output destination of the 
received packet by referring to the routing table 337. The 
network kernel 323 edits the packet according to a fil- 
tering condition of a differentiated service set in advance 
in the kernel. When the output destination is a virtual 

45 device, the process branches to step S204. When the 
output destination is a physical device, the packet is 
transferred to this device. 

[0091] At step S204, the network kernel 323 delivers 
the information of the transferred packet to the MAVPN 

50 control section 322, and the MAVPN control section 322 
carries out a tunneling and encryption of the packet 
based on the information set in advance. In the case of 
encapsulating the IP packet by the tunneling process- 
ing, the MAVPN control section 322 carries over the 

55 TOS information of the original packet. The IP packet 
that has been edited is returned to the network kernel 
323 again. Then, the network kernel 323 transfers the 
packet to a corresponding physical device by referring 
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to the routing table 337 based on a given new destina- 
tion of the IP packet. 

[0092] Fig. 18 shows an example of a processing flow 
of the MA protocol control section 321 . First, the MA pro- 
tocol control section 321 checks a port number of a re- 5 
ceived packet. When this port number is a port number 
of the AAA protocol, the process proceeds to step S206. 
When this port number is a port number of the mobile 
IP protocol, the process proceeds to step S207 (S205). 
At step S206, the MA protocol control section 321 starts 
the AAA protocol processing section 331 to process the 
AAA protocol (reference Fig. 19). Thereafter, the MA 
protocol control section 321 extracts the mobile IP pro- 
tocol added to the AAA protocol as a part of the infor- 
mation, and delivers the processing to step S207. At 
step S207, the MA protocol control section 321 starts 
the mobile IP protocol processing section 332, and then 
finishes the processing. 

[0093] Fig. 1 9 shows an example of a processing flow 
of the AAA protocol processing section 331 . First, the 
AAA protocol processing section 331 extracts the VPN 
information from a received AAA protocol, and then de- 
livers this VPN information to the VPN information cache 
333. Next, the AAA protocol processing section 331 sets 
a flag on a shared memory to indicate that the cache 
has been set and updated, for the mobile IP protocol 
processing section 332 to refer to this fact (S208). After 
finishing the AAA protocol processing, the AAA protocol 
processing section 331 extracts the mobile IP protocol 
added to the AAA protocol as a part of the information 
(S209). When the received message is a position reg- 
istration request message (HAR), the AAA protocol 
processing section 331 transmits a position registration 
response message (HAA) (S210 and S211). 
[0094] Fig. 20 shows an example of a processing flow 
of the mobile IP protocol processing section 332. At step 
S212, the mobile IP protocol processing section 332 
makes a decision on the type of a received mobile IP 
protocol message. When the type of the received mobile 
IP protocol message is a registration request, the proc- 
ess proceeds to step S213. When the type of the re- 
ceived mobile IP protocol message is a registration re- 
sponse, the process proceeds to step S220. When the 
type of the received mobile IP protocol message is a BU 
(Binding Update) or a BA (Binding Acknowledge), the 
process proceeds to step S218. 

A. In the case of the registration request 

[0095] When the MA that has received the registration 50 
request is the HA, the mobile IP protocol processing 
section 332 compares the carc-of-address of the regis- 
tration request message with the old care-of-address 
within the mobility binding. When these care-of-ad- 
dresses do not coincide with each other as a result of 55 
the comparison, the process proceeds to step S214. 
When these care-of-addresses coincide with each other 
as a result of the comparison or when the MA that has 



received the registration request is the FA, the process 
branches to step S21 7 (S21 3). At step S214, the mobile 
IP protocol processing section 332 specifies the VPN 
information cache instance of the MN that has transmit- 
ted the position registration message, and rewrites the 
destination GW address of the VPN information cache 
333 to the address posted by the care-of-address. 
[0096] This specification method can be achieved by 
providing an IP address of the MN to the session ID, or 
by providing a link between the mobility binding and the 
VPN information cache instance. The HA searches all 
the VPN information profiles set in the specified VPN 
information cache instance. When the destination GW 
type is one to which a dynamic VPN can be set, the HA 
edits the BU message that has set the VPN information 
to the transmission originating address of this profile, 
and transmits this edited BU message (S215). At step 
S216, the mobile IP protocol processing section 332 
starts the MAVPN control section 322, and edits the re- 
ception message and the message specified by the 
processing MA as shown in a message correspondence 
table in Fig. 21, and transmits the edited result (S217). 

B. In the case of the registration response 

[0097] At step S220, the mobile IP protocol'process- 
ing section 332 refers to the cache update information 
set in advance in the shared memory by the V AAA pro- 
tocol processing section 331 . When there has v: been an 
updating in the cache, the process branches 1 to step 
S216. When there has been no updating in the cache, 
the process branches to step S21 7. 

C. In the case of the BU or BA — 

[0098] At step S218 : when the received message is 
the BU, the process branches to step S219, and when 
the received message is the BA, the process branches 
to step S217. When the processing MA is the PCN, the 
mobile IP protocol processing section 332 receives all 
the BU messages addressed to the CN under the man- 
agement of the PCN, on behalf of the CN. This system 
can be achieved by, for example, the method disclosed 
in Japanese Patent No. 2000-32372. When the 
processing MA is the PCN, the mobile IP protocol 
processing section 332 sets the VPN information set in 
the BU message to the VPN information cache 333, or 
substitutes the message with this VPN information. 
When the processing MA is the FA, the mobile IP pro- 
toco! processing section 332 updates the destination 
GW address of the VPN information cache 333 to a new 
FA address (S219). 

[0099] Fig. 22 shows an example of a processing flow 
of the MAVPN control section 322. The MAVPN control 
section 322 starts the QoS control section 334 at step 
S221 , and starts the tunnel control section 335 at the 
next step S222. 

[0100] Fig. 23 shows an example of a processing flow 



15 



20 



25 



30 



35 



40 



9 



BNSDOCID <EP _1 17678 1A2J._> 



17 



EP 1 176 781 A2 



18 



of the QoS control section 334. First, at step S223, the 
OoS control section 334 deletes the information of the 
differentiated service that has been set to the network 
kernel 323 based on the information of the VPN infor- 
mation instance. Next 3 when the TOS value of the VPN 
information instance is other than zero (0), the QoS con- 
trol section 334 branches the process to step S225. 
When the TOS value of the VPN information instance is 
not other than zero (0), the QoS control section 334 fin- 
ishes the processing (S224). At step S225, the QoS con- 
trol section 334 sets the information of the differentiated 
service to the network kernel based on the information 
of the VPN information instance (S225). 
[01 01 ] Fig. 24 shows an example of a processing flow 
of the tunnel control section. First, the tunnel control sec- 
tion deletes the information in the route table 337 that 
has been set to the network kernel 323 and the corre- 
sponding information in the information table 336 based 
on the information of the VPN information instance 
(S226). Next, the tunnel control section sets the output 
destination of the route table at the destination address 
set in the VPN information profile of the VPN information 
instance to a virtual device (S227). Further, the tunnel 
control section sets the tunnel information instance of 
the IP Sec. information table 336 by referring to the VPN 
information profile of the VPN information instance 
(S228). 

[0102] At step S229, the tunnel control section refers 
to the security type within the VPN information profile of 
the VPN information instance. When the ESP or the AH 
has been assigned, the process branches to step S230. 
When the ESP or the AH has not been assigned, the 
tunnel control section finishes the processing. At step 
S230 : the tunnel control section refers to the SPI within 
the VPN information profile of the VPN information in- 
stance. When the SPI is a user individual SPI, the proc- 
ess proceeds to step S231. When the SPI is a default 
SPI, the process proceeds to step S232. It is assumed 
that this default SPI has been set to MA in advance at 
the time of the initial structuring or from a local mainte- 
nance console of the MA. At step S231 , the tunnel con- 
trol section sets the key information relevant to the SPI 
of the VPN information profile of the VPN information 
instance to the ESP information instance. At step S232, 
the tunnel control section sets the ESP identifier to the 
IP Sec. information instance. 

[0103] Various other embodiments of the present in- 
vention separate from the above-described first embod- 
iment will be explained below in order to further enhance 
the understanding of the operation of the present inven- 
tion, based on the items described above. 
[0104] Fig. 25 shows a second embodiment of the 
present invention. 

[0105] This shows an example of a setting of a VPN 
(when a VPN exists between a stationary HA and a CN) 
at the time of amove within thesamedomain. This sche- 
matically shows how a VPN is reconstructed when the 
MN 1 of a user has moved from the FA 21 of the roaming- 



contracted ISP 2 of the first embodiment to other FA 21 ' 
of the same roaming-contracted ISP 2 after a VPN has 
been set to the GW 51 of the enterprise domain. 
[0106] In Fig. 25. when the MN 1 of the user has 
5 moved from the FA 21 to a new FA 2Y within the same 
domain, a registration request message (Reg Req) that 
includes the address of the old FA 21 is transmitted as 
prescribed in the mobile IP path optimization draft (draft- 
ietfmobileip-optim-09) (3) ). The new FA 2V includes 
10 this registration request into an authentication request 
message (AMR) ((2) ), and transmits this authentication 
request message (AM R) to the local AAA server (AAAF) 
23 within its own ISP 2. When the authentication request 
message (AMR) includes the old FA 21, the AAAF 23 
'5 extracts the VPN between the FA and the HA from the 
VPN information cache, and substitutes the address of 
the FA 21 with the address of the new FA 21 Then, the 
AAAF 23 returns to the new FA 21' an authentication 
response message (AMA) that is added with a profile of 
20 the VPN to be set to the FA (® ). 

[0107] The FA 2V transfers the registration request 
message (Reg Req) received from the MN 1 to the HA 
31 (© )• The HA 31 specifies a VPN profile from the HA 
to the FA from the VPN information cache, and rewrites 
25 the address of the FA to the address of the new FA 21 '. 
Next, the HA 31 deletes the IP Sec. tunnel to the old FA 
21 , and sets a new IP Sec. tunnel (1 ) to the new FA 21 '. 
The HA 31 finishes a position registration processing, 
and then returns the registration response message 
30 (Reg Rep) to the FA 21 ' (® ). 

[0108] The FA 2V maps an assigned differentiated 
service by referring to the VPN information cache, and 
then sets an IP Sec. tunnel (2) from the FA 21' to the HA 
31 . The FA 21 ' then sets the information for decoding a 
35 packet of an opposite-direction tunnel to the IP Sec. in- 
formation table. Further, the FA 21' copies the VPN in- 
formation cache, and rewrites the transmission originat- 
ing GW address to the address of the old FA 21 and 
rewrites the destination GW address to the address of 
40 the new FA 21'. Thereafter, the FA 21 1 adds this VPN 
information to the BU message, and transmits this mes- 
sage to the old FA 21 (© ). 

[0109] The old FA 21 caches the VPN information 
added to the BU message, deletes the IP Sec. tunnel 

45 directed from the FA 21 to the HA 31 , and maps an as- 
signed differentiated service. Thereafter, the FA 21 sets 
an IP Sec. tunnel (3) at the smooth-hand-off time from 
the old FA 21 to the new FA 21 As a result, all the pack- 
ets addressed to the MN 1 and received by the old FA 

50 21 before the changeover of the IP Sec. to the new IP 
Sec. tunnel (1) tunnel by the HA 31 are transferred to 
the new FA 21 ' via this IP Sec. tunnel (3). The old FA 21 
returns the BA message to the MN after completing the 
setting of the IP Sec. tunnel (3) (® )- Based on this, the 

55 new FA 21' returns the registration response message 
(Reg Rep) to the MN 1 (® ). 

[0110] Fig. 26 shows a third embodiment of the 
present invention. 
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[0111] This shows an example of a setting of a VPN 
(when a VPN exists between a stationary HA and a CN) 
at the time of a move between different domains. This 
schematically shows how a VPN is reconstructed when 
the MN 1 of a user has moved from the FA 21 of the 
roaming-contracted ISP 2 of the first embodiment to oth- 
er FA 21' of a different roaming-contracted ISP 2' after 
a VPN has been set from the FA 21 to the GW 51 of the 
enterprise domain. 

[0112] In Fig. 26, when the MN 1 of the user has 
moved between different domains 2 and 2\ the user 
transmits a registration request (Reg Req) in a proce- 
dure similar to that of a normal initial position registration 
as prescribed in the DIAMETER mobile expansion draft 
(drattietl-calhoun-diameter-mobileip-o8) © ). The FA 
2V of the move destination includes this registration re- 
quest into the authentication request message (AMR) 
(d) ), and transmits this authentication request message 
(AMR) to the AAA (AAAH) 33 of the user home ISP via 
a local AAA server (AAAF) 22' within the own FA 21*. 
[0113] As the two VPNs including the VPN between 
the FA and the HA and the VPN between the HA and 
the enterprise GW have already been set to the VPN 
information cache, the AAAH 33 rewrites the address of 
the FA of the VPN between the FA and the HA to the 
address of the new FA 2V. Next, the AAAH 33 transmits 
to this HA 31 a position registration request message 
(HAR) added with the profiles of the two VPNs (@ ). The 
HA 31 updates the cache based on the VPN information 
added to the position registration request message 
(HAR), deletes the IP Sec. tunnel directed from the HA 
31 to the old FA 21 , and sets a new IP Sec. tunnel (1) 
to the new FA 21 '. Then, after finishing the position reg- 
istration processing, the HA 31 returns the position reg- 
istration response message (HAA) to the AAAH (@ ). In 
this case, the HA 31 returns the address information of 
the old FA 21 as additional information. 
[0114] Upon receiving the position registration re- 
sponse message (HAA), the AAAH 33 extracts the VPN 
between the FA and the HA from the VPN information 
cache, and transmits to an AAAF 23' an authentication 
response message (AMA) added with the VPN profile 
to be set to the FA ((S) ). The AAAF 23* caches the VPN 
information to within the AAAF in order to correspond to 
the move within the local domain of the MN 1 , and trans- 
fers this information to the FA 21*. The FA 2V caches 
the VPN information added to the authentication re- 
sponse message (AMA), maps an assigned differenti- 
ated service, and then sets an IP Sec. tunnel (2) from 
the FA 21 * to the HA 31. Further, the FA 21' sets the 
information for decoding a packet of an opposite-direc- 
tion tunnel to the IP Sec. information. 
[0115] Further, when the authentication response 
message (AMA) includes the old FA address, the FA 21 ' 
copies the VPN information cache, and rewrites the 
transmission originating GW address to the address of 
the old FA 21 and rewrites the destination GW address 
to the address of the new FA 2V. Thereafter, the FA 21' 



adds this VPN information to the BU message, and 
transmits this message to the old FA 21 (@ ). The old 
FA 21 caches the VPN information added to the BU 
message, deletes the IP Sec. tunnel directed from the 

5 FA 21 to the HA 31 , and maps an assigned differentiated 
service. Thereafter, the FA 21 sets an IP Sec. tunnel (3) 
at the hand-off time from this FA 21 to the new FA 21 \ 
[0116] As a result, all the packets addressed to the 
MN 1 and received by the old FA 21 before thexhange- 

w over of the IP Sec. tunnel to the new IP Sec. tunnei (1 ) 
by the HA 31 are transferred to the new FA 21 ' via this 
IP Sec. tunnel (3). The FA 21 returns the BA message 
to the new FA 21 ' after completing the setting of the IP 
Sec. tunnel (3) (© ). Based on this, the new FA 2V re- 

15 turns the registration response message (Reg Rep) to 
the MN 1 ((§)). 

[01 17] According to the above-described'second and 
third embodiments, a user who communicates with the 
enterprise via the ISP can receive the service of a VPN 
20 corresponding to a mobile terminal provided by the ISP, 
without requiring the GW apparatus of the enterprise to 
have a specific function. 

[0118] Fig. 27 shows a fourth embodiment of the 
present invention. 

25 [0119] This shows an example of a setting of a VPN 
(when a PCN exists) at the time of an initial position reg- 
istration. This schematically shows an example of a set- 
ting of a VPN when a roaming-contracted iSP of a com- 
munication destination has a VPN and a GW (PCN) lo 

30 which a VPN can be set dynamically. The ISP that has 
a VPNGW to which a VPN can be set dynamically reg- 
isters a domain address of the ISP and a GW apparatus 
address in the CN-GW correspondence tableof each 
provider at the time of making the roaming contract be-. 

35 tween ISPs, thereby making it possible to dynamically 
set a VPN by type of GW. 

[0120] In Fig. 27, a user joining any one ISP among 
the roam-contracted ISPs connects to a near access 
point, and transmits a position registration request (Reg 

40 Req) of the mobile IP from this MN 1 ©), The FA21 
includes this registration request in an authentication re- 
quest message (AMR), and transmits this authentica- 
tion request message to the AAA (AAAH) 33 of the home 
ISP 3 of the user via the local AAA sever (AAAF) 23 

45 within the own ISP (© ). 

[0121] The AAAH searches the VPN database 34 by 
the NAI included in the authentication request message 
(AMR), and extracts the VPN information own to this us- 
er. When an address assigned as a user communication 

50 destination in the VPN database 34 is within the roam- 
ing-contracted ISP 4, it can be known from the CN-GW 
address correspondence table that it is possible to dy- 
namically set a VPN. Therefore, the AAAH sets a VPN 
of the GW (PCN) between the FA and the communica- 

55 tion ISP 4 to the VPN information cache. Next, the AAAH 
transmits a position registration request message 
(HAR) added with the profile of this VPN, to the HA 31 
(® ). The HA 31 caches the VPN information added to 
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the position registration request message (HAR). After 
finishing the position registration processing, the HA 31 
can dynamically set a VPN by referring to a type of the 
GW of the communication destination GW 41 set to the 
VPN information. Therefore, the HA 31 transmits an MIP 
Binding update message BU added with this VPN infor- 
mation addressed to a communication terminal CN 42 
(®). 

[0122] A PCN 41 receives the BU transmitted to the 
CN 42 on behalf of the CN 42, and caches the VPN in- 
formation added to the BU. Th PCN 41 maps a differen- 
tiated service according to the posted VPN information, 
and sets an IP Sec. tunnel (1) from the PCN 41 to the 
FA 21 . Thereafter, the PCN 41 transmits an MIP Binding 
Acknowledge message BA to the HA 31 (© ). When the 
HA 31 has received the BA, the HA 31 returns the po- 
sition registration response message (HAA) to the 
AAAH 33 ((§) ). Upon receiving the position registration 
response message (HAA), the AAAH 33 extracts a VPN 
of the GW (PCN) between the FA and the communica- 
tion destination ISP 4 from the VPN information cache. 
The AAAH 33 then transmits to the AAAF 23 an authen- 
tication response message (AMA) added with the VPN 
profile to be set to the FA 21 (© ). The AAAF 23 caches 
the VPN information within the AAAF 23 to follow the 
move within the local domain of the MN 1 , and transfers 
this VPN information to the FA 21 . 

[0123] The FA 21 caches the VPN information added 
to the authentication response message (AMA), and fur- 
ther maps an assigned differentiated service. Thereaf- 
ter, the FA 21 sets an IP Sec. tunnel (2) from the FA 21 
to the PCN 41 . Further, the FA 21 sets the information 
for decoding a packet of an opposite-direction tunnel to 
the IP Sec. information table. Thereafter the FA 21 re- 
turns the registration response message (Reg Rep) to 
the MN ((§) ). As a result, the user can carry out a VPN 
communication with an optional communication desti- 
nation within the roaming-contracted ISP group. 
[0124] Fig. 28 shows a fifth embodiment of the 
present invention. 

[0125] This shows an example of a setting of a VPN 
(when a PCN exists) at the time of a move within the 
same domain. This schematically shows how a VPN is 
reconstructed when the MN 1 of a user has moved from 
the FA 21 of the roaming-contracted ISP 2 of the fourth 
embodiment to other FA 21' of the same roaming-con- 
tracted ISP 2 after a VPN has been set from this FA 21 
to a PCN 41 of other optional roaming-contracted ISP 4. 
[0126] In Fig. 28, when the MN 1 of the user has 
moved from the FA 21 to the FA 21' within the same 
domain, a registration request message (Reg Req) that 
includes the address of the old FA 21 is transmitted as 
prescribed in the mobile IP path optimization draft (draft- 
ietfmobileip-optim-09) 0) )• The new FA 21' includes 
this registration request into an authentication request 
message (AMR), and transmits this authentication re- 
quest message (AMR) to the local AAA server (AAAF) 
23 within its own ISP 2 (@ )• When the authentication 



request message (AMR) includes the old FA 21, the 
AAAF 23 extracts the VPN between the FA and the PCN 
from the VPN information cache, and substitutes the ad- 
dress of the FA 21 with the address of the new FA 21'. 
5 Then, the AAAF 23 returns to the new FA 21 ' an authen- 
tication response message (AMA) that is added with a 
profile of the VPN to be set to the FA (® ). 
[0127] The FA 21' transfers the registration request 
message (Reg Req) previously received from the MN 1 
10 to the HA 31 f® ). The HA 31 specifies a VPN profile of 
the VPN utilized by this MN 1 from the VPN information 
cache, and rewrites the address of the FA to the address 
of the new FA 21'. In the present embodiment, the VPN 
has already been directly set to between the FA 21 and 

15 the PCN 41. Therefore, the HA 31 posts this effect to 
the PCN 41 by the BU message (® ). Whether the BU 
message is to be transmitted or not is determined based 
on whether the type of the communication destination 
GW of the VPN information cache is the one to which a 

20 VPN can be set dynamically or not. 

[0128] Next, the PCN 41 deletes the IP Sec. tunnel to 
the old FA 21 based on the reception of the BU, and sets 
a new IP Sec. tunnel (1) to the new FA 21'. Thereafter, 
the PCN 41 transmits the BA message to the HA 31 

25 ((§) ). Based on the reception of the BA message, the 
HA 31 transmits the registration response message 
(Reg Rep) to the new FA 21 ' (© ). The new FA 21 ' maps 
an assigned differentiated service by referring to the 
VPN information cache, and then sets an IP Sec. tunnel 

30 (2) from the new FA 21 ' to the PCN 41 . The FA 21 ' then 
sets the information for decoding a packet of an oppo- 
site-direction tunnel to the IP Sec. information table. 
Further, the FA 21' copies the VPN information cache, 
and rewrites the transmission originating GW address 

35 to the address of the old FA 21 and rewrites the desti- 
nation GW address to the address of the new FA 2V. 
Thereafter, the FA 21' adds this VPN information to the 
BU message, and transmits this message to the old FA 
21 (® ). 

40 [0129] The old FA 21 caches the VPN information 
added to the BU message, deletes the IP Sec. tunnel 
directed from the old FA 21 to the PCN 41, and maps 
an assigned differentiated service. Thereafter, the FA 21 
sets an IP Sec. tunnel (3) at the smooth-hand-off time 

45 from the old FA 21 to the new FA 2 V. As a result, all the 
packets addressed to the MN 1 from the PCN 41 and 
received by the FA 21 before the changeover of the IP 
Sec. tunnel to the new IP Sec. tunnel (1 ) are transferred 
to the new FA 2V via this IP Sec. tunnel (3). The old FA 

50 21 returns the BA message to the MN after completing 
the setting of the IP Sec. tunnel (3) ((g) ). Based on this, 
the new FA 21' returns the registration response mes- 
sage (Reg Rep) to the MN 1 ((9) '). 
[0130] Fig. 29 shows a sixth embodiment of the 

55 present invention. 

[0131] This shows an example of a setting of a VPN 
(when a PCN exists) at the time of a move between dif- 
ferent management domains. This schematically shows 
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how a VPN is reconstructed when the MN 1 of a user 
has moved from the FA 21 of the roaming-contracted 
ISP 2 of the fourth embodiment to other FA 21 1 of a dif- 
ferent roaming-contracted ISP 2' after a VPN has been 
set from this FA 21 to a PCN 41 of other optional roam- 
ing-contracted ISP 4. 

[0132] In Fig. 29, when the MN 1 of the user has 
moved between different domains 2 and 2\ the user 
transmits a registration request message (Reg Req) in 
a procedure similar to that of a normal initial position 
registration as prescribed in the DIAMETER mobile ex- 
pansion draft (draft-ietf-calhoun-diameter-mobileip-o8) 
fQ) ). The FA 2V of the move destination includes this 
registration request message into the authentication re- 
quest message (AMR), and transmits this authentica- 
tion request message (AMR) to the AAA (AAAH) 33 of 
the user home ISP via a local AAA server (AAAF) 23' 
within the own ISP (® ). As the VPN between the FA21 
and the PCN 41 has already been set to the VPN infor- 
mation cache, the AAAH 33 rewrites the address of this 
FA 21 to the address of the new FA 21 '. Next, the AAAH 
33 transmits to this HA 31 a position registration request 
message (HAR) added with the profiles of this VPN 

[0133] The HA 31 updates the cache based on the 
VPN information added to the position registration re- 
quest message (HAR), and transmits the BU message 
to the PCN. 41 (@ ). Upon receiving the BU message, 
the PCN 41 deletes the IP Sec. tunnel to the old FA 21 , 
and sets a new IP Sec. tunnel (1) to the new FA 21 \ 
Thereafter, the PCN 41 transmits the BA message to 
the HA 31 ((D ). Upon receiving the BA message, the 
HA 31 returns the position registration response mes- 
sage (HAA) to the AAAH 33 (® ). In this case, the HA 
31 returns the address information of the old FA 21 as 
additional information. 

[0134] Upon receiving the position registration re- 
sponse message (HAA), the AAAH 33 extracts the VPN 
between the FA and the HA from the VPN information 
cache, and transmits to an AAAF 23' an authentication 
response message (AMA) added with the VPN profile 
to be set to the FA ((7) ). The AAAF 23' caches the VPN 
information within the AAAF in order to correspond to 
the move within the local domain of the MN 1 , and trans- 
fers this information to the new FA 2V. The new FA 21' 
caches the VPN information added to the authentication 
response message (AMA) : maps an assigned differen- 
tiated service, and then sets an IP Sec. tunnel (2) from 
the FA 2V to the PCN 41. Further, the FA 21' sets the 
information for decoding a packet of an opposite-direc- 
tion tunnel to the IP Sec. information. 
[0135] When the authentication response message 
(AMA) includes the address of the old FA 21 like this 
case, the FA 21 1 copies the VPN information cache, and 
rewrites the transmission originating GVV address to the 
address of the old FA 21 and rewrites the destination 
GW address to the address of the new FA 21V Thereaf- 
ter, the FA 21 ' adds this VPN information to the BU mes- 



sage, and transmits this message to the old FA 21 (® ). 
The old FA 21 caches the VPN information added to the 
BU message, deletes the IP Sec. tunnel directed from 
the old FA 21 to the PCN 41, and maps an assigned 
5 differentiated service. Thereafter, the FA 21 sets an IP 
Sec. tunnel (3) at the smooth-hand-off time from this FA 
21 to the new FA 2V. 

[0136] As a result, all the packets addressed to the 
MN 1 from the PCN 41 and received by the old FA 21 

10 before the changeover of the IP Sec. tunnel are trans- 
ferred to the new FA 2V via this IP Sec. tunnel (3). The 
old FA 21 returns the BA message to the MN after com- 
pleting the setting of the IP Sec. tunnel (3) (® ). Based 
on this, the new FA 21 ' returns the registration response 

is message (Reg Rep) to the MN 1 ((§) '). As shown in the 
fifth and sixth embodiments, according to the present 
invention, a user who is a member of the roaming-con- 
tract ISP group can set a VPN with any optional com- 
munication destination within this group. Further, this 

20 user can move freely within this group with the VPN un- 
changed. 

[0137] Fig. 30 shows a seventh embodiment of the 
present invention. 

[0138] This shows an example of a setting of a VPN 

25 between optional terminals assigned by the user. While 
the above-explained examples are for setting^ VPN to 
a specific communication destination assigned by the 
user, it is also possible for the user to dynamically set a 
VPN to a communication destination. The present em- 

30 bodiment shows an example of case where the user 
sets a VPN to a communication destination other than 
the communication destination that has beenassigned 
by the user when the contract was made. 
[0139] A user who wants a change of a VPN setting 

35 destination makes access to a home page of a VPN 
service customize provided by a home ISP 3 of the user. 
The user sets an address of a communication destina- 
tion through this home page. A WEB application 36 
linked with this home page changes the VPN informa- 

40 tion of the user in a VPN database 34 to the information 
assigned by the user (J) ). When the customizing has 
been finished, the MN 1 of the user transmits a position 
registration request message (Reg Req) added with a 
service update request to an FA 21 to which the user is 

45 currently connected (© ). Upon receiving the registra- 
tion request added with the service update request, the 
FA 21 includes this registration request into an authen- 
tication request message (AMR), and transmits this au- 
thentication request message (AMR) to an AAA (AAAH) 

50 33 of the user home ISP via a local AAA server (AAAF) 
23 within the own ISP (® ). 

[0140] The AAAH 33 receives the message added 
with the service update request regardless of whether 
the VPN information cache already exists or not, and 
55 searches a VPN database 34 with an NAI included in 
the authentication request message (AMR), and ex- 
tracts the VPN information to this user. When the ad- 
dress assigned as the user communication destination 
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in the VPN database 34 is within the roaming-contracted 
ISP, it can be known from a CN-GW address corre- 
spondence table that a VPN can be dynamically set to 
this communication destination. Therefore, according to 
the present embodiment, the AAAH 33 sets a VPN for 5 
a GW (PCN) 41' between the FA 21 and the communi- 
cation destination ISP in the VPN information cache. 
Then, the AAAH 33 transmits to the HA 31 a position 
registration request message (HAR) added with the pro- 
file of this VPN (0 ). 10 
[0141] The HA 31 caches the VPN information added 
to the position registration request message (HAR). Af- 
ter finishing the position registration processing, the HA 
31 can dynamically set a VPN by referring to a type of 
the GW of the communication destination GW 41 1 set to '5 
the VPN information. Therefore, the HA 31 transmits an 
MIP Binding update message BU added with this VPN 
information addressed to a communication terminal CN 
42' «D ). 

[0142] The PCN 4V receives the BU transmitted to 20 
the CN 42' on behalf of the CN 42', and caches the VPN 
information added to the BU message. Th PCN 41' 
maps a differentiated service according to the posted 
VPN information, and sets an IP Sec. tunnel (1 ) from the 
PCN 41 ' to the FA 21 . Thereafter, the PCN 41 ' transmits 25 
an MIP Binding Acknowledge message BA to the HA 31 

((D)- 

[0143] When the HA 31 has received the BA mes- 
sage, the HA 31 returns the position registration re- 
sponse message (HAA) to the AAAH 33 (© ). Upon re- 30 
ceiving the position registration response message 
(HAA), the AAAH 33 extracts a VPN of the GW (PCN) 
41' between the FA 21 and the communication destina- 
tion ISP from the VPN information cache. The AAAH 33 
then transmits to the AAAF 23 an authentication re- 35 
sponse message (AMA) added with the VPN profile to 
be set to the FA 21 (® ). The AAAF 23 caches the VPN 
information to within the AAAF 23 to follow the move 
within the local domain of the MN 1, and transfers this 
VPN information to the FA 21 . 40 
[0144] The FA 21 caches the VPN information added 
to the authentication response message (AMA), and fur- 
ther maps an assigned differentiated service. Thereaf- 
ter, the FA 21 sets an IP Sec. tunnel (2) from the FA 21 
to the PCN 4V. Further, the FA 21 sets the information ^ 
for decoding a packet of an opposite-direction tunnel to 
the IP Sec. information table. Thereafter, the FA 21 re- 
turns the registration response message (Reg Rep) to 
the MN ((§) ). When a VPN that has been set before the 
change of the VPN exists, the PCN 41 transmits a Bind- so 
ing request message BR to the HA 31 that has posted 
this VPN information and asks whether the VPN can be 
deleted or not, when the remaining lifetime has become 
less than a threshold value ((§) ). 

[0145] Upon receiving this BR message, the HA 31 55 
searches a VPN information cache from the information 
of the MN 1 that has been set to this message, and 
checks whether the VPN relating to this PCN 41 still ex- 



ists in the cache. When this VPN has still been cached, 
the HA 31 transmits a BU message to the PCN 41 . When 
the VPN has not been cached, the HA 31 transmits no 
BU message to the PCN 41 . In the present example, the 
PCN 41 deletes an existing VPN as no BU can be re- 
ceived until the completion of the lifetime. As explained 
above, the user can also dynamically assign a VPN set- 
ting destination. In the present embodiment, an example 
of assigning a VPN setting destination only through the 
WEB has been shown. However, the gist of the present 
invention is the distribution of the VPN information to an 
assigned setting destination and the setting/releasing 
means of this VPN information under a mobile environ- 
ment. There are various methods of assigning a com- 
munication destination and means for reflecting them to 
the VPN database 34. For example, there are various 
applications such as a dialing of a VPN code with a com- 
munication destination using a portable telephone, and 
a one-click setting of a VPN from a communication serv- 
er, etc. 

[0146] As explained above, the present invention has 
the following effects. 

1 ) It is possible to provide a VPN setting service to 
between optional terminals without requiring an MN 
and a CN to have a specific VPN function. This is 
achieved by dynamically setting a VPN of the IP 
Sec. to a security gateway of terminals participating 
in communications, to a public IP network, linked 
with a position registration procedure in the mobile 
IP. 

2) It is possible to set a VPN with the service quality, 
the security level, and the route, assigned by users 
based on a free combination. 

3) It is possible to automatically update a VPN path 
along with a move of an MN. 



Claims 

1. A server apparatus provided in a home network of 
an IP network using a protocol that automates the 
management of an IP address and the transfer of a 
communication packet to a move destination when 
a terminal has moved between networks on the IP 
network, the server apparatus comprising: 

memory means that stores information for con- 
structing a safe communication path within an 
IP network in relation to the terminal; and 
distribution means that distributes the informa- 
tion to construct a safe communication path be- 
tween the terminal within an external network 
of a move destination and the other terminal 
with whom the terminal communicates. 

2. The server apparatus according to Claim 1 , wherein 

the distribution means transfers the informa- 
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tion to a router of an external network in which the 
other terminal exists. 

3. The server apparatus according to Claim 1 , wherein 

Ahe safe communication path is a communi- ■ 5 
cation path realized by a virtual private network, and 
the information includes set path information and 
security information of the virtual private network. 

4. The server apparatus according to Claim 1 , wherein io 

the distribution means distributes the informa- 
tion at the time of transmitting an authentication re- 
sponse message to a position registration request 
message from the terminal. 

75 

5. The server apparatus according to Claim 1 , wherein 

the distribution means distributes the informa- 
tion after receiving a communication packet from 
the other terminal that becomes the communication 
destination. 20 

6. A VPN system in a mobile IP network, the VPN sys- 
tem comprising: 

a mobile terminal; ^5 
a home authentication server provided in a 
home network of a user and an external authen- 
tication server provided in other external net- 
work; 

, a VPN database provided in the home network; 30 
and 

network apparatuses that have gateway func- 
tions of a home network, an external network, 
a predetermined communication host and/or an 
agent server therefor, wherein 35 
the home authentication server extracts from a 
VPN database VPN information of a user who 
has requested an authentication at the time of 
a position registration request from a mobile 
terminal, and posts this VPN information to 40 
each network apparatus by using a predeter- 
mined position registration message and an au- 
thentication response message, and 
the respective network apparatuses set a VPN 
path by the IP Sec. based on posted VPN in- 45 
formation, to between the home network appa- 
ratus and the external network apparatus, be- 
tween the home network apparatus and the 
predetermined network apparatus, and/or be* 
tween the external network apparatus and the .50 
predetermined network apparatus respectively. 

7. The VPN system according to Claim 6, wherein 

, the authentication server and the network ap- 55 
paratus update VPN information cached in the 
authentication server and the network appara- 
tus to new path information or rewrite the VPN 



information with position information.linked with 
a position registration request based on a move 
of a mobile terminal, thereby to automatically 
update each VPN path between the home net- 
work apparatus and the external network appa- 
ratus, between the home network apparatus 
and the predetermined network apparatus, 
and/or between the external network apparatus 
and the predetermined network apparatus/to a 
new VPN path based on the IP Sec. respective- 
ly. 

8. ■ The VPN system according to Claim 6 ; wherein the 

home authentication server includes: 

an AAAVPN control section that specifies a 
VPN set path from the information of the exter- 
nal network apparatus connected by the mobile 
terminal set in a predetermined authentication 
request message and the information of the 
home network apparatus of the mobile termi- 
nal, by using a correspondence table showing 
a correspondence between the VPN informa- 
tion of the VPN database and a predetermined 
network apparatus accommodating a commu- 
nication host held by itself; and ^ 
an AAA protocol processing apparatus that 
sets a service quality between the network ap- 
. paratuses and security information to^a prede- 
termined authentication response message to 
an access network and to a position registration 
' message to the home network, as service pro- 
files. 

*i 

9. The VPN system according to Claim 6, -wherein 
each network apparatus includes: 

an MA protocol processing section that controls 
protocols relating to a service profile in which 
the VPN information has been set by caching; 
and 

an MAVPN control section that sets a QoS con- 
trol for guaranteeing the service quality and a 
tunnel for guaranteeing the security between 
the security gateways according to the service 
profile. 

10. An external authentication server existing with a 
. mobile terminal in an IP network using a protocol 

that automates the management of an IP address 
and the transfer of a communication packet to a 
move destination when the terminal has moved be- 
tween networks on the IP network, the external au- 
thentication server comprising: 

means that extracts safety path information 
corresponding to a user included in a response 
message from a home authentication server 
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when the mobile terminal has made a position 
registration request; and 
safety path construction instruction means that 
instructs a network apparatus accommodating 
the mobile terminal to construct a safe commu- 5 
nication path between this network apparatus 
and a network apparatus accommodating the 
other terminal as a communication destination, 
based on the extracted safety path information. 

10 

11. The external authentication server according to 
Claim 10, wherein 



12. The external authentication server according to 20 
Claim 11 , wherein 

the safe communication path is a VPN path ac- 
cording to the IP Sec. 

25 

13. A network apparatus for accommodating a mobile 
terminal in an IP network using a protocol that au- 
tomates the management of an IP address and the 
transfer of a communication packet to a move des- 
tination when a terminal has moved between net- 30 
works on the IP network, the network apparatus 
comprising: 



14. The network apparatus according to Claim 13, 
wherein 

the safe communication path is a communica- so 
tion path realized by a virtual private network, 
and the safety path information includes set 
path information and security information of the 
virtual private network. 

55 

15. The network apparatus according to Claim 14, 
wherein 



the safe communication path is a VPN path ac- 
cording to the IP Sec. 

16. A VPN setting method in a mobile IP network com- 
prising the steps: 

that a user network apparatus sets VPN path 
by a stationary IP Sec. tunnel directed from the 
user network apparatus to its home agent; 
that a user mobile terminal transmits a position 
registration request message to a foreign 
agent; 

that the foreign agent transmits an authentica- 
tion request message including the received 
position registration request information to a 
user home authentication server via a local au- 
thentication server of the foreign agent; 
that, based on the received authentication re- 
quest message, the home authentication serv- 
er refers to its own database and extracts a 
communication destination host, a type of the 
network apparatus, and security service infor- 
mation by users, caches the VPN information 
between the foreign agent and the home agent 
and between the user network apparatus and 
the home agent, and transmits the position reg- 
istration request message including this infor- 
mation to the home agent; 
that the home agent caches the received posi- 
tion registration request message, sets the as- 
signed security service, sets a VPN path by an 
IP Sec. tunnel directed from the home agent to 
the user network apparatus as a communica- 
tion destination host and to the foreign agent 
respectively, and transmits a position registra- 
tion response message to the home authenti- 
cation server after finishing the position regis- 
tration processing; 

that, based on the reception of the position reg- 
istration response message, the home authen- 
tication server transmits the authentication re- 
sponse message added with the cached VPN 
information between the foreign agent and the 
home agent., to a local authentication server of 
the foreign agent; 

that the local authentication server transmits 
the received authentication response message 
to the foreign agent after caching the VPN in- 
formation between the home agent and the for- 
eign agent; and 

that the foreign agent caches the VPN informa- 
tion included in the received authentication re- 
sponse message, sets the assigned security 
service, sets a VPN path by an IP Sec. tunnel 
directed from the foreign agent to the home 
agent, and then returns the position registration 
response message to the user mobile terminal. 



the safe communication path is a communica- 
tion path realized by a virtual private network, is 
and the safety path information includes set 
path information and security information of the 
virtual private network. 



means that receives a safety path construction 
instruction based on safety path information 35 
corresponding to a user included in a response 
message from a home authentication server 
when the mobile terminal has made a position 
registration request; and 

safety path construction means that constructs *o 
a safe communication path between this net- 
work apparatus and a network apparatus ac- 
commodating the other terminal as a commu- 
nication destination, based on the received 
safety path construction information. 
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17. The VPN setting method according to Claim 1 6, fur- 
ther comprising the steps: 

that the user mobile terminal moves to an area 
of a new foreign agent within the same network. 5 
and transmits from there a position registration 
request message including position information 
of the old foreign agent; 

that the new foreign agent transmits an authen- 
tication request message including the re- io 
ceived position registration request information 
to the local authentication server; 
that the local authentication server rewrites the 
foreign agent information of the cached VPN in- 
formation between the foreign agent and the '5 
home agent to the information of the new for- 
eign agent, and transmits an authentication re- 
sponse message including this information to 
the new foreign agent; 

that the new foreign agent transfers the re- 20 
ceived position registration request message to 
the home agent; 

that, based on the received position registration 
request information, the home agent rewrites 
the" foreign agent information of the cached 25 
VPN information between the foreign agent and 
the home agent to the information of the new 
foreign agent, deletes the VPN path directed 
from the home agent to the old foreign agent, 
■ sets a VPN path by an IP Sec. tunnel directed 30 
from the home agent set with the assigned se- 
curity service to the new foreign agent, and 
transmits a position registration response mes- 
sage to the new foreign agent after finishing the 
position registration processing; and 35 
that the new foreign agent caches the VPN in- 
formation included in the received position reg- 
istration response message, sets the assigned 
security service, sets a VPN path by an IP Sec. 
tunnel directed from the new foreign agent to 40 
the home agent, and then returns the position 
registration response message to the user mo- 
bile terminal. 



18. The VPN setting method according to Claim 1 6, fur- 
• trier comprising the steps: 



45 



that the user mobile terminal moves to an area 
of a new foreign agent within a different net- 
work, and transmits from there a position reg- 50 
istration request message including position in- 
formation of the old foreign agent; 
that the new foreign agent transmits an authen- 
tication request message including the re- 
ceived position registration request information 55 
to the home authentication server of the user 
via a local authentication server of the new for- 
eign agent; 



that the home authentication server rewrites 
the foreign agent information of the cached 
VPN information between the foreign agent and 
the home agent to the information of the new 
foreign agent, and transmits the position regis- 
tration request message including this informa- 
tion to the home agent; 

that, based on the received position registration 
request information, the home agent updates 
the cached VPN information, deletes the VPN 
path directed from the home agent to the old 
foreign agent, sets a VPN path by an IP Sec. 
tunnel directed from the home agent set with 
the assigned security service to the new foreign 
• agent, and transmits a position registration re- 
sponse message to the home authentication 
server after finishing the position registration 
processing; 

that, based on the reception of the position reg- 
istration response message, the home authen- 
tication server transmits the authentication re- 
sponse message added with the cached VPN 
information between the foreign agent and the 
home agent, to a local authentication server of 
the new foreign agent; 

that the local authentication server transmits 
the received authentication response message 
to the new foreign agent after updating the 
cached VPN information; and 
that the new foreign agent caches theVPN in- 
formation included in the received authentica- 
tion response message, sets the assigned se- 
curity service, sets a VPN path by an IP Sec. 
tunnel directed from the new foreign agent to 
the home agent, and then returns the position 
registration response message to the user mo- 
, bile terminal. 

19. A VPN setting method in a mobile IP network com- 
prising the steps: 

that a user mobile terminal transmits a position 
registration request message from the user mo- 
bile terminal to a foreign agent; 
that the foreign agent transmits an authentica- 
tion request message including the received 
position registration request information to a 
user home authentication server via a local au- 
thentication server of the foreign agent; 
that, based on the received authentication re- 
quest message, the home authentication serv- 
er refers to its own database and extracts a 
communication destination host, a type of the 
network apparatus, and security service infor- 
mation by users, sets a VPN between the for- 
eign agent and the communication destination 
network apparatus to a VPN cache when the 
type of the network apparatus is a one to which 
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a VPN can be set dynamically, and transmits 
the position registration request message in- 
cluding this information to the home agent: 
that the home agent caches the received posi- 
tion registration request message, and trans- 5 
mits a binding update message added with this 
VPN information to the communication destina- 
tion host after finishing the position registration 
processing, when the type of the network ap- 
paratus is a one to which a VPN can be set dy- 10 
namically; 

that the network apparatus receives the binding 
update message on behalf of the communica- 
tion destination host, caches the VPN informa- 
tion added to this message, sets the assigned '5 
security service, sets a VPN path by an IP Sec. 
tunnel directed from the network apparatus to 
the foreign agent, and thereafter transmits a 
binding authorization message to the home 
agent; 20 
that, upon receiving the binding authorization 
message, the home agent transmits a position 
registration response message to the home au- 
thentication server; 

that, based on the reception of the position reg- 25 
istration response message, the home authen- 
tication server transmits the authentication re- 
sponse message added with the cached VPN 
information between the foreign agent and the 
network apparatus, to a local authentication 30 
server of the foreign agent; 
that the local authentication server transmits 
the received authentication response message 
to the foreign agent after caching the VPN in- 
formation added to this message; and 35 
that the foreign agent caches the VPN informa- 
tion included in the received authentication re- 
sponse message, sets the assigned security 
service, sets a VPN path by an IP Sec. tunnel 
directed from the foreign agent to the network *o 
apparatus, and then returns the position regis- 21. 
tration response message to the user mobile 
terminal. 



20. The VPN setting method according to Claim 1 9, fur- 
ther comprising the steps: 



45 



that the user mobile terminal moves to an area 
of a new foreign agent within the same network, 
and transmits from there a position registration so 
request message including position information 
of the old foreign agent; 

that the new foreign agent transmits an authen- 
tication request message including the re- 
ceived position registration request information 55 
to the local authentication server; 
that the local authentication server rewrites the 
foreign agent information of the cached VPN in- 



formation between the foreign agent and the 
network apparatus to the information of the new 
foreign agent, and transmits an authentication 
response message including this information to 
the new foreign agent; 

that the new foreign agent transfers the re- 
ceived position registration request message to 
the home agent; 

that, based on the received position registration 
request information, the home agent rewrites 
the foreign agent information of the cached 
VPN information between the foreign agent and 
the network apparatus to the information of the 
new foreign agent, and transmits a binding up- 
date message added with this VPN information 
to the communication destination host, when 
the type of the network apparatus is a one to 
which a VPN can be set dynamically; 
that, based on the received binding update 
message, the network apparatus updates the 
cached VPN information, deletes the VPN path 
directed from the network apparatus to the old 
foreign agent, sets a VPN path by an IP Sec. 
tunnel directed from the network apparatus set 
with the assigned security service to the new 
foreign agent, and thereafter transmits a cou- 
plingauthorization message to the home agent; 
that, upon receiving the binding authorization 
message, the home agent transmits a position 
registration response message to the new for- 
eign agent: and 

that the new foreign agent caches the VPN in- 
formation included in the received position reg- 
istration response message, sets the assigned 
security service, sets a VPN path by an IP Sec. 
tunnel directed from the new foreign agent to 
the network apparatus, and then returns the po- 
sition registration response message to the us- 
er mobile terminal. 

The VPN setting method according to Claim 1 9, fur- 
ther comprising the steps: 

that the user mobile terminal moves to an area 
of a new foreign agent within a different net- 
work, and transmits from there a position reg- 
istration request message including position in- 
formation of the old foreign agent; 
that the new foreign agent transmits an authen- 
tication request message including the re- 
ceived position registration request information 
to the home authentication server of the user 
via a local authentication server of the new for- 
eign agent; 

that the home authentication server rewrites - 
the foreign agent information of the cached 
VPN information between the foreign agent and 
the home agent to the information of the new 
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foreign agent, and transmits the position regis- 
tration request message including this informa- 
tion to the home agent; 

that, based on the received position registration 
request information, the home agent updates 5 
the cached VPN information, and transmits a 
binding update message added with this VPN 
information to the communication destination 
host when the type of the network apparatus is 
a one to which a VPN can-be set dynamically; io 
that, based on the received binding update 
message, the network apparatus updates the 
cached VPN information, deletes the VPN path 
directed from the network apparatus to the old 
foreign agent, sets a VPN path by an IP Sec. '5 
tunnel directed from the network apparatus set 
with the assigned security service to the new 
foreign agent, and thereafter transmits a bind- 
ing authorization message to the home agent; 
that, upon receiving the binding authorization 20 
message, the home agent transmits a position 
registration response message to the new for- 
eign agent; 

that, based on the reception of the position reg- 
istration response message, the home authen- 25 
lication server transmits the authentication re- 
sponse message added with the cached VPN 
information between the foreign agent and the 
network apparatus, to a local authentication 
server of the new foreign agent; 30 
that the local authentication server transmits 
the received authentication response message 
to the new foreign agent after caching the VPN 
information added to this message; and 
that the new foreign agent caches the VPN in- 35 
formation included in the received position reg- 
istration response message, sets the assigned 
security service, sets a VPN path by an IP Sec. 
tunnel directed from the new foreign agent to 
the network apparatus, and then returns the po- *o 
sition registration response message to the us- 
er mobile terminal: 

22. The VPN setting method according to Claim 17 or 

20, further comprising the steps: 45 

that the new foreign agent copies the cached 
A/PN information, and transmits a binding up- 
date message added with the VPN information 
with the transmission origin rewritten to the old 50 
foreign agent and with the transmission desti- 
nation rewritten to the new foreign agent, to the 
old foreign agent; and 

that, the old foreign agent caches the VPN in- 
formation of the received binding update mes- 55 
sage, deletes the VPN path directed from the 
oldforeign agent to the home agent, sets a VPN 
path by an IP Sec. tunnel directed from the old 



foreign agent set with the assigned security 
service to the new foreign agent, and thereafter 
transmits a coupling authorization message to 
the new foreign agent. 

23. The VPN setting method according to Claim 18 or 
21 , further comprising the steps: 

that the new foreign agent copies the cached 
VPN information when the authentication re- 
sponse message includes the information of 
the old foreign agent, and transmits a binding 
update message added with the VPN informa- 
tion with the transmission origin rewritten to the 
old foreign agent and with the transmission 
destination rewritten to the new foreign agent, 
to the old foreign agent; and 
that, the old foreign agent caches the VPN in- 
formation of the received coupling update mes- 
sage, deletes the VPN path directed from the 
old foreign agent to the home agent, sets a VPN 
path by an IP Sec. tunnel directed from the old 
foreign agent set with the assigned security 
service to the new foreign agent, and thereafter 
transmits a coupling authorization message to 
the new foreign agent. ^ 

24. The VPN setting method according to Claim 1 9, fur- 
ther comprising the steps: ^ 

that the user customizes the user VPN informa- 
tion by making access to a database of the 
home authentication server by predetermined 
communication means, and thereby'changes 
the communication destination to a network ap- 
paratus of the type of the network apparatus to 
which a VPN can be set dynamically; and 
the user mobile terminal transmits a position 
registration request message added with a 
service update request, to a foreign agent. 

25. The VPN setting method according to Claim 24, fur- 
ther comprising the steps: 

that the network apparatus measures a lifetime 
of a communication host under its manage- 
ment, transmits a binding request message to 
the home agent that has posted the VPN infor- 
mation when the remaining lifetime has be- 
come less than a predetermined threshold val- 
ue, and deletes the VPN information when the 
binding update message has not been re- 
ceived; and 

the home agent retrieves the cached VPN in- 
formation from the user mobile terminal infor- 
* mation included in the received binding request 
message, transmits a binding update message 
when the information of the network apparatus 
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exists, and leaves it as it is when the informa- 
tion of the network apparatus does not exist. 
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